Java is an object oriented language that is used in a wide variety of applications and devices. Java-based applications are robust, portable across multiple platforms, and provide a highly dynamic run time environment.
If a field of a Java class is declared to be static, exactly one incarnation of this field exists, regardless of how many instances of the class may eventually be created. A static field, which is sometimes referred to as a class variable, is created when the class is initialized. Initialization of a class involves the execution of special code blocks, referred to herein as static initializers, and the initializers of static fields declared in the class. Initialization of a Java interface involves executing the initializers for fields declared in the Java interface. As used herein, the term “Java interface” refers that which is described as an “interface” in the Java Language Specification. Java does not restrict the code that is executed in the static initializers or the initializers of the static fields in terms of resource consumption—objects and threads can be created during the initialization process without limitation.
A class or Java interface type T will be initialized immediately before one of the following occurs: (1) T is a class and an instance of T is created; (2) T is a class and a static method of T is invoked; or (3) A nonconstant static field of T is used or assigned. A constant field is a field that is either explicitly or implicitly both final and static and is initialized with the value of a compile-time constant expression. It should be noted that fields of Java interfaces are implicitly public static and final. A reference to nonconstant static field must be resolved at the compilation time to a copy of the compile-time constant value, so that uses of such a field never cause initialization.
The Java language defines the concept of threads. Threads independently execute code that operates on values and objects residing in a shared main memory. Virtual machines usually support the execution of multiple threads at a time. The Java programming language supports the coding of programs that, though concurrent, still exhibit deterministic behavior by providing mechanisms for synchronizing the concurrent activity of threads. To synchronize threads, the Java programming language uses monitors, which are high-level mechanisms for allowing only one thread at a time to execute a region of code or a complete method protected by the monitor. The behavior of monitors is explained in terms of locks; there is a lock associated with each object.
A synchronized method automatically performs a lock action when it is invoked; the body is not executed until the lock action has successfully completed. If the method comprises an instance method, it locks the lock associated with the instance for which it was invoked. If the method is static, it locks the lock associated with the class object that represents the class in which the method is defined. If the execution of the method's body is ever completed (either normally or abruptly), an unlock action is automatically performed on that same lock.
OSGi, which stands for “Open Services Gateway Initiative” and is discussed at the URL www.osgi.org, is an open, common architecture to deploy and manage services in a coordinated manner. OSGi provides a general-purpose, secure, managed Java-based framework that supports the deployment of extensible and downloadable service applications known as bundles. OSGi-compliant devices can download and install OSGi deployment entities and remove them when they are no longer required. Installed and started bundles can register a number of services that can be shared with other bundles under strict control of the framework.
OSGi can run on the top of a standard Java virtual machine (VM). Contrary to traditional methods where one Java application runs on one VM, several bundles can be simultaneously run on the same VM in OSGi. Using OSGi, there is no need to load and execute the VM as many times as the number of the running Java applications. Thus, memory consumption is greatly reduced.
OSGi bundles have a well-defined lifecycle, which is depicted in FIG. 1. The framework reports the lifecycle changes of bundles to other bundles via events of class “BundleEvent”.
In order to ensure that the resource consumption of the OSGi runtime is not growing continuously, when a bundle is stopped, it must release all of the resources that had been allocated since activation, as is required in Section 4.8.7 of the current OSGi R3 specification. According to Section 4.8.7 of the OSGi R3 specification, the BundleActivator interface defines a “public void stop (BundleContext context) throws Exception” method, which is invoked by the framework to stop a bundle. This method must release any resources that were allocated since activation. All threads associated with the stopping bundle should be stopped immediately.
An important feature of bundles is that they are able to share Java code with other bundles. Technically, this is achieved by exporting a part of the Java packages contained by the bundle, permitting other bundles to import and use these packages. Package sharing in the standard OSGi framework is depicted in FIG. 4. Exported packages may contain any kind of Java code. Bundles that import the same exported packages of another bundle will see the same incarnations of static fields. The availability of the exported packages is tied to the lifecycle stages of the bundle; the exported packages must be made continuously available while the bundle is cycling between RESOLVED and ACTIVE states. If the bundle's dependencies are resolved, selected packages must be exported. Packages exported by a stopped bundle continue to be available to other bundles. This continued export implies that other bundles can execute code from a stopped bundle.
OSGi also introduces the concept of “service.” According to the current OSGi R3 framework specification, for the OSGi service platform, bundles are built around a set of cooperating services that are available from a shared service registry. Such an OSGi service is defined semantically by its service interface and is implemented as a service object. The service interface should be specified with as few implementation details as possible. The service object is owned by, and runs within, a bundle. This bundle must register the service object with the framework service registry so that the service's functionality is available to other bundles under the control of the framework.
Dependencies between the bundle that owns the service and the bundles using the service are managed by the framework. For example, when a bundle is stopped, all of its services registered with the framework will be automatically unregistered. The framework maps services to their underlying service objects and provides a query mechanism that enables an installed bundle to request the services it needs. The framework also provides an event mechanism so that bundles can receive events of service objects that are registered, modified, or unregistered.
For the reporting of registration, unregistration, and property changes of service objects, all events of this type must be delivered synchronously.
The OSGi specifications currently require that a stopping bundle must stop its threads and clean up its resources. At the same time, OSGi does not specify any infrastructure that makes this requirement enforceable. Malicious bundles or bug-prone bundles may ignore this requirement. As a result, only a full restart of the framework can address this issue. Unfortunately, a full restart interrupts the availability of the functionality provided by the OSGi runtime. In a system that is expected to run in a 24/7 environment and provide crucial functionality, such a deficiency is not tolerable.
The OSGi specifications also require that the exported packages of a bundle need to be available even when a bundle is stopped. The users or importers of the exported packages must not experience the exported packages becoming inconsistent as a consequence of the stopping of the exporting bundles. An OSGi-compliant solution for forced bundle stopping must ensure these requirements. However, the forceful termination of a bundle and the reclamation of its resources can result in this precise problem. Therefore, the forced stopping must reclaim only the resources that are not visible by the users of the exported packages.
Due to the activities performed in the static initializers, as well as the activities performed in the initializers of static fields of the classes contained by the exported packages and those packages that are not actually exported but are used from the code of exported packages, a bundle may consume resources and may create and start threads even if it has never been started (i.e. the bundle is stays in the RESOLVED state). Bundles staying in the RESOLVED state cannot be stopped, since the stop operation is defined only for bundles being in the ACTIVE state. OSGi does not define any facilities that can be used to ask such a bundle in the RESOLVED state to clean up its resources.
It would therefore be desirable to develop a system and method that enables the possibility of forced resource reclamation without having to restart the whole OS process running the Java VM that powers the OSGi runtime.